In Debian and Ubuntu, there are some patches that change the rustc/fonts
directory to a symlink to the system fonts. This triggers a latent bug
in linkchecker, as the DirEntry filetype isn't a dir but later on the
file itself, when opened, is one, triggering an unreachable!() clause.

This patch fixes the situation by using std::fs::metadata, which goes
through symlinks.

I'd have added a test case but `tidy` doesn't seem to like symlinks, and
moreover I'm not sure how Git deals with symlinks on Windows.

Signed-off-by: Simon Chopin <[email protected]>

fixes rust-lang#91139
fixes rust-lang#91069

- Implement lowering for subtype goals
- Use correct lang item for Generator trait
- Use `lower_into` for lowering `ty::Variance`

This is required to avoid creating large numbers of universes from each
Chalk query, while still having enough universe information for lifetime
errors.

canonicalize_chalk_query -> canonicalize_query_preserving_universes

Add 2 tests

fixes rust-lang#91139
fixes rust-lang#91069

Add some known GAT bugs as tests

In the spirit of rust-lang/compiler-team#476

These tests are marked as "check-fail", but also commented with "this should pass". This many of the open GAT issues that are accepted bugs.

r? `@nikomatsakis`

Pretty print ItemKind::Use in rustfmt style

This PR backports the formatting for `use` items from https://github.com/dtolnay/prettyplease into rustc_ast_pretty.

Before:

```rust
use core::{cmp::{Eq, Ord, PartialEq, PartialOrd},
    convert::{AsMut, AsRef, From, Into},
    iter::{DoubleEndedIterator, ExactSizeIterator, Extend, FromIterator,
    IntoIterator, Iterator},
    marker::{Copy as Copy, Send as Send, Sized as Sized, Sync as Sync, Unpin
    as U}, ops::{*, Drop, Fn, FnMut, FnOnce}};
```

After:

```rust
use core::{
    cmp::{Eq, Ord, PartialEq, PartialOrd},
    convert::{AsMut, AsRef, From, Into},
    iter::{
        DoubleEndedIterator, ExactSizeIterator, Extend, FromIterator,
        IntoIterator, Iterator,
    },
    marker::{
        Copy as Copy, Send as Send, Sized as Sized, Sync as Sync, Unpin as U,
    },
    ops::{*, Drop, Fn, FnMut, FnOnce},
};
```

…niverses, r=jackh726

Improve chalk integration

- Support subtype bounds in chalk lowering
- Handle universes in canonicalization
- Handle type parameters in chalk responses
- Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty`
- Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE)

This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are:

- rust-lang/chalk#234
- rust-lang/chalk#548
- rust-lang/chalk#734
- Generators are handled differently in chalk and rustc

r? `@jackh726`

…rk-Simulacrum

bootstrap.py: Suggest disabling download-ci-llvm option if url fails to download

I got an error when trying to build the compiler using an old commit, and it turns out it was because the option `download-ci-llvm` was implicitly set to true. So this pull request tries to add a help message for other people that may run into the same problem.

To reproduce my error:

```
git checkout 8d7707f
./x.py test
[...]
spurious failure, trying again
downloading https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
curl: (22) The requested URL returned error: 404

failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmp8g13rb4n https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
Build completed unsuccessfully in 0:00:46
```

This is my `config.toml`:

```
# Includes one of the default files in src/bootstrap/defaults
profile = "compiler"
changelog-seen = 2

[rust]
debug = true
```

To reproduce an error with this branch:

Change line 618 of bootstrap.py to
```
        url = "rustc-builds-error404/{}".format(llvm_sha)
```

Delete llvm and cached tarball, and set `llvm.download-ci-llvm=true` in config.toml.

```
./x.py test
[...]
spurious failure, trying again
downloading https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
curl: (22) The requested URL returned error: 404

failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmpesl1ydvo https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:

[llvm]
download-ci-llvm = false

Build completed unsuccessfully in 0:00:01
```

Regarding the implementation, I expected to be able to use a try/catch block in `_download_ci_llvm`, but the `run` function calls `sys.exit` instead of raising an exception so that's not possible. Also, suggestions for better wording of the help message are welcome.

…Mark-Simulacrum

linkchecker: fix panic on directory symlinks

In Debian and Ubuntu, there are some patches that change the rustc/fonts
directory to a symlink to the system fonts. This triggers a latent bug
in linkchecker, as the DirEntry filetype isn't a dir but later on the
file itself, when opened, is one, triggering an unreachable!() clause.

This patch fixes the situation by using std::fs::metadata, which goes
through symlinks.

I'd have added a test case but `tidy` doesn't seem to like symlinks, and
moreover I'm not sure how Git deals with symlinks on Windows.

Signed-off-by: Simon Chopin <[email protected]>

…Mark-Simulacrum

tidy: Extend error code check

We discovered in rust-lang#93845 that the error code tidy check didn't check everything: if you remove an error code from the listing even if it has an explanation, then it should error.

It also allowed me to put back `E0192` in that listing as well.

r? `@Mark-Simulacrum`

Add missing release notes for rust-lang#85200

Fixes rust-lang#93894